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METHOD AND APPARATUS FOR AN IMPROVED INTERFACE 
BETWEEN COMPUTER COMPONENTS 

5 

FIELD OF INVENTION 

The present invention relates to the field of computer systems, and, 
in particular, the field of providing an improved interface between 
computer components. 

10 

BACKGROUND OF THE INVENTION 

Modern computer systems include a Central Processing Units (CPU 
101) interconnected to system memory 103 (i.e., the CPU/memory 

15 subsystem.) As shown in Figure 1, data and other signals are transmitted 
between the CPU and system memory via a component commonly 
referred to as a host bridge 105. The host bridge 105 may also provide 
other components and/ or subsystems in a computer with an interface to 
the CPU/ memory subsystem. 

20 For example, as further shown in Figure 1, peripheral components 

(e.g., a keyboardl09, disk drive 110 and/or mouse 111) may be 
interconnected to each other via a input/output (I/O) bridge 107. The 
I/O bridge 107, in turn, may be interconnected with the host bridge 105 to 
provide an interface between the peripherals and the CPU/memory 

25 subsystem. 



-2- 



042390.P6341X 



Additional external busses (e.g., a Peripheral Component 
Interconnect (PCI) bus 113), however, may also join the interface between 
the I/O bridge 107 and the CPU/memory subsystem* As a result, the 
interface between the I/O bridge 107 and CPU/ memory subsystem is 
further complicated and restricted by the specifications/ requirements of 
an external bus 113 (e.g., PCI) which joins the interface between the I/O 
bridge 107 and the CPU/memory subsystem. 

As a result, there is a need for an improved interface between 
peripheral components and the processor/ memory subsystems. 



-3- 



042390. 



SUMMARY OF THE INVENTION 



The present invention provides an interface to transfer data 
between a memory control hub (MCH) and a input/output control hub 
(ICH) within a computer system, including a data signal path to transmit 
data between hubs in packets via split transactions, and 
a set of command signals, wherein the interface provides a point-to-point 
connection between the MCH and the ICH, exclusive of an external bus 
connected directly to the interface. 
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BRIEF DESCRIPTION OF THE DRAWINGS 

The present invention is illustrated by way of example and not 
limitation in the figures of the accompanying drawings, in which like 
references indicate similar elements, and in which: 

5 

Figure 1 illustrates a computer system implementing an interface 
between computer components according to the prior art. 

Figure 2 is a block diagram of one embodiment of a computer 
10 system implementing the improved interface between computer 
components. 

Figure 3 is a timing diagram illustrating a split transaction 
implemented by one embodiment of an interface. 

15 

Figure 4 is a block diagram of one embodiment of a computer 
system implementing a hierarchy of multiple improved interfaces 
between computer components. 

20 Figure 5 is a timing diagram illustrating arbitration and 

transmission of data packets, according to one embodiment. 

Figure 6 is a timing diagram illustrating flow control of data 
packets, according to one embodiment. 

25 

Figure 7 illustrates a flow diagram describing the steps of 
responding to flow control operations according to one embodiment. 
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¥ f 



Figure 8 illustrates the physical signal interface according to one 
embodiment. 

5 Figure 9 is a timing diagram illustrating source synchronous 

clocking according to one embodiment. 

Figure 10 illustrates a computer system having multiple processors 
implementing an improved interface between computer components 
10 according to one embodiment. 

Figure 11 is a block diagram of one embodiment of a computer 
system implementing the improved interface between computer 
components, wherein a central processing unit is integrated with a 
15 computer component. 

Figure 12 is a block diagram of one embodiment of a computer 
system implementing the improved interface between computer 
components, wherein a central processing unit is integrated with a 
20 computer component, and a graphics unit. 
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DETAILED DESCRIPTION 

An improved interface between computer components is described. 
The interface may be referred to, herein, as a hub-interface. The hub- 
5 interface is an interface for connecting building blocks of core logic via a 
narrow and high bandwidth interface. 

In the following description, numerous details are set forth. It will 
be apparent, however, to one skilled in the art, that the present invention 
may be practiced without these specific details. In other instances, well- 
10 known structures and devices are shown in block diagram form, rather 
than in detail, in order to avoid obscuring the present invention. 

As illustrated in Figure 2, one embodiment of the hub-interface 
provides individual components with a point-to-point interface. In 
alternative embodiments, however, the hub-interface may provide an 
15 interface between three or more components. 

More specifically, Figure 2 illustrates one embodiment of the hub- 
interface 204 used to interconnect two separate components (i.e., hub 
agents) within a chipset. The hub agents provide a central connection 
between two or more separate buses and/or other types of 
20 communication lines. 

For example, as further shown in Figure 2, the chipset includes a 
memory control hub 204 (MCH) and an input/output (ICH) hub 206. The 
memory control hub 204, as shown in Figure 2, provides an 
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interconnection/hub between one or more Central Processing Units 208 
(CPU) and the system memory 210. 

The ICH 206 provides an interconnection between various 
peripheral components within the system (e.g. a keyboard 218, disk drive 
5 224, scanner 222 and/or mouse 220.) Moreover, the external busses and 
their agents (e.g., Peripheral Component Interconnect (PCI) bus 212 and 
PCI agents 214), interconnect indirectly with the memory 210 and CPU 
208 via the hub-interface 202, by interconnecting with the ICH 206, rather 
than interconnecting directly with the memory control hub 204. 

10 By using the hub-interface to interconnect the memory control hub 

204 and the ICH 206, improved access is provided between 1/ O 
components and the CPU/ memory subsystem (e.g., increased bandwidth, 
protocol independence, and lower latency.) In addition, the hub-interface 
may also improve the scalability of a computer system (e.g., upgrading 

15 from a base desktop platform to high-end desktop platforms or 

workstation platform) by providing a backbone for I/O building blocks. 

In an alternative embodiment, the CPU and the MCH are 
integrated on a single semiconductor unit 230, as shown in figure 11, 
wherein the single semiconductor unit 230 is coupled to the ICH via the 

20 hub-interface. In another alternative embodiment, the MCH and a 
graphics unit 232 (e.g. control/accelerator) are integrated on a single 
semiconductor unit 230, as shown in Figure 12, wherein the single 
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semiconductor unit 230 is coupled to the ICH via the hub-interface. In yet 
another alternative embodiment, the MCH, the graphics unit 232 and the 
CPU are integrated on a single semiconductor unit 230, wherein the single 
semiconductor unit 230 is coupled to the ICH via the hub-interface. 
5 To provide the improved interface, the hub-interface includes one 

or more unique features. In one embodiment, transactions are transferred 
across the hub-interface using a packet based split-transaction protocol. 
For example, a request packet is used to start a transaction and a separate 
completion packet may subsequently be used to terminate a transaction, if 
10 necessary. 

Figure 3 illustrates an example of a split transaction across the hub- 
interface. As illustrated in Figure 3, a hub agent initially obtains 
ownership of the hub-interface via arbitration 302. Following the 
arbitration, there is a request phase 304. If necessary (e.g., in the case of 
15 returning data for a read transaction), a completion phase 308 will follow 
the request phase. Prior to the completion phase, however, the 
responding hub agent, will first arbitrate 306 for ownership of the hub- 
interface. 

In between the time of transmitting a request packet and a 
20 corresponding completion packet across the hub-interface, separate 
unrelated packets may be transmitted across the hub-interface in 
accordance with predetermined order rules, as discussed below in more 
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detail For example in the case of a read request from a peripheral to 
memory, providing the requested data may take multiple clock cycles to 
have the data ready to be returned in a completion packet. During the 
time it takes to obtain the requested data, separate unrelated completion 
5 and /or request packets waiting in a queue/pipe of the memory control 
hub 204 may be transmitted to the ICH 206. 

Furthermore, as shown in Figure 3, each request or completion is 
transmitted as a packet across the interface. For write type transactions, 
data is associated with the request. For read type transactions, there will 
10 be data associated with the completion. In some cases, there will be more 
than one completion for a request for the case where the completion 
packet is disconnected, effectively splitting it into multiple completion 
packets. 

In addition, in one embodiment, the hub-interface uses transaction 
15 descriptors for routing of hub-interface traffic as well as identifying the 
attributes of a transaction. For instance, the descriptors may be used to 
define a transaction as isochronous or asynchronous, which, as a result, 
may then be handled in accordance with a predefined protocol. 

Furthermore, in one embodiment, the bandwidth of the interface is 
20 increased in part by transmitting the data packets via a source 

synchronous clock mode. Moreover, in one embodiment, the hub- 
interface provides the increased bandwidth despite using a narrow 
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connection (e.g., less pins/pads than have typically been used in the prior 
art). 

In alternative embodiments, however, a hub-interface may be 
implemented with less than all of the unique features as discussed above, 
5 without departing from the scope of the invention. Moreover, the hub- 
interface could also be used to interconnect bridges and and/ or other 
components within or external to a chipset, without departing from the 
scope of the present invention. 



10 TRANSACTION, PROTOCOL AND PHYSICAL LAYERS 

For greater clarity, the hub-interface is described in three parts: a 
transaction layer; a protocol layer; and a physical layer. The distinctions 
between layers, however, is to be regarded in an illustrative rather than a 
restrictive sense, and is therefore does not imply a particular preferred 
15 embodiment. 

TRANSACTION LAYER 

In one embodiment of the hub-interface, the transaction layer 
supports the routing of separate transactions transmitted across the hub- 
interface (which may consist of one or more packets.) For example, in one 
20 embodiment, the transaction layer of the hub-interface generates 
transaction descriptors, which are included in the requests and data 
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packets. The transaction descriptors may be used to support arbitration 
between queues within a hub agent (e.g., MCH), and/ or to facilitate 
routing of requests and data packets through the hub-interface. 

For instance, in one embodiment, the transaction descriptors 
5 support routing of completion packets back to the request-initiating agent 
based on initially supplied (within a request packet) routing information. 
The transaction descriptors also help to reduce or possibly packet- 
decoding logic within the hub agents. 

In alternative embodiments, the transaction descriptors also 
10 provide the ability to distinguish the handling of requests based on their 
respective transaction attributes. For instance, the transaction attributes 
identified in the transaction descriptors may identify operations as 
Isochronous (i.e., operations that move fixed amounts of data on a regular 
basis; e.g., video or audio real time operations.) As a result, the 
15 operations, as identified by the transaction attributes, may be handled in 
accordance with a corresponding predetermined routing protocol in order 
to support a specific type of operation (e.g., isochronous.) 

In one embodiment, the transaction descriptors include two fields: 
a routing field and an attribute field. In alternative embodiments, more 
20 or less fields may be used to provide one or more of the functions of the 
transaction descriptors, without departing from the scope of the 
invention. 
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In one embodiment, the routing field is a six-bit field used for 
packet routing, as shown below in Table 1. The size of the routing field, 
as well as the attribute field, may vary within the scope of the invention. 

Table 1 Routing Field of Transaction Descriptor 



Hub ID 



Pipe ID 



As shown in Table 1, three bits of the routing field are used for the 
Hub ID which identifies the hub agent that initiated the transaction. In 
alternative embodiments, to provide a hub-interface hierarchy exceeding 
8, additional bits could be used in the routing field. 

1 0 For example, there may exist multiple hub-interface hierarchies in a 

system, in which case the agent at the top of the hierarchies should be 
capable of routing completions back to the base of the hierarchy. In this 
context, "hierarchy" consists of multiple connected hub-interface 
segments starting from a hub-interface "root" agent (e.g., a Memory 

15 Control Hub.) For instance, Figure 2 illustrates a system having only one 
hub-interface hierarchy. Figure 4, however, illustrates an example of 
system based on two hub-interface hierarchies. In embodiments 
implementing only one hub-interface hierarchy, a default value of "000" 
may be used in the Hub ID field. 
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The remaining three bits of the routing field may be used to 
identify internal pipes/ queues within a hub-interface agent. For example 
the ICH may support internal USB (Universal Serial Bus) host control 
traffic and Bus Mastering ID (BM-ID) traffic via separate "pipes." As such, 
5 the Pipe ID may be used communicate to the servicing agent (e.g., MCH) 
that traffic initiated by different "pipes" have different attributes, and may 
be handled in accordance with a predetermined protocol. If a hub- 
interface agent does not implement separate internal pipes, it may use a 
default value of "000" in the Pipe ID field. 

10 In an alternative embodiment, the transaction descriptors further 

include an attribute field. In one embodiment, the attribute field is a 
three-bit value, which specifies how a transaction is to be handled when a 
target hub-interface agent receives it. In some cases, the attribute field 
helps a system support demanding application workload, which relies on 

15 the movement, and processing of data with specific requirements or other 
differentiating characteristics. 

For example, the attribute field may support the isochronous 
movement of data between devices, as used by a few recently developed 
external busses (e.g., IEEE 1394 and USB.) Such data movement 
20 requirements need to be maintained as data flows through the hub- 
interface between I/O devices and the CPU/memory subsystem. 
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In alternative embodiments, additional transaction attributes may 
include the ability to differentiate between "snooped" traffic where cache 
coherency is enforced by hardware (Le v chipset) and "non-snooped" 
traffic that relies on software mechanisms to ensure data coherency in the 
5 system. Moreover, another possible attribute would be an "explicitly 
prefetchable" hint, to support a form of read caching and allow for more 
efficient use of the main memory bandwidth. 

Ordering Rules 

The transaction descriptors can also be used to support ordering 
10 rules between transactions transmitted across the hub-interface. For 
example, in one embodiment, transactions with identical transaction 
descriptors are executed in strong order (i.e., first come - first serve.) 

Transactions having the same routing field but different attribute 
fields, however, may be reordered with respect to each other. For 
15 example, in one embodiment, isochronous transactions do not need to be 
strongly ordered with respect to asynchronous transactions. 

In addition, in one embodiment of the hub-interface interface, data 
transmissions are permitted to make progress over requests, either in the 
same direction or the opposite direction. Read completions flowing in one 
20 direction are allowed to pass read requests flowing in the same direction. 
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And, write requests are allowed to pass read requests flowing in the same 
direction. 

In alternative embodiments, however, the ordering rules for 
transactions travelling across the hub-interface interface, may vary within 
5 the scope of the invention. For example, in one embodiment, the hub- 
interface implements the ordering rules provided in Peripheral 
Component Interconnect (PCI) (Revision 2.2) to determine the flow of 
traffic across the hub-interface in opposite directions. 

PROTOCOL LAYER 

10 In one embodiment, the hub-interface uses a packet-based protocol 

with two types of packets: request and completion. A request packet is 
used for each hub-interface transaction. Completion packets are used 
where required, for example, to return read data, or to acknowledge 
completion of certain types of write transactions (e.g., I/O writes and 

15 memory writes with requested completion). Completion packets are 
associated with their corresponding request packets by transaction 
descriptors and ordering, as previously discussed in the section on the 
Transaction Layer. 

In addition, in one embodiment, the hub-interface interface uses an 
20 arbitration protocol that is symmetric and distributed. For example, each 
hub agent drives a request signal, which is observed by the other agent 
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attached to the same interface. No grant signal is used, and agents 
determine ownership of the interface independently. 

Moreover, in one embodiment, no explicit framing signal is used. 
There is an implied relationship between the arbitration event that gives 
5 an agent ownership of the interface and the start of that agent's 

transmission. In alternative embodiment, framing signals could be used 
without departing from the scope of the invention. 

The end of a packet transmission occurs when a hub-interface agent 
that owns the interface (e.g., is in the process of transmitting data) releases 
10 its control of the interface by de-asserting a request signal. In addition, in 
one embodiment, flow control is also accomplished by using a STOP 
signal to retry or disconnect packets, as is described in more detail below. 

Packet Definition 

In one embodiment of the hub-interface, data is transferred at a 
15 multiple rate (e.g., lx, 4x, 8x) of the hub-interface clock (HLCK), which in 
one embodiment is a common clock shared by the hub agents joined by 
the hub-interface. The data is transmitted across a data signal path (PD) of 
the hub-interface, which has an "interface width" of some power of two 
(e.g., 8, 16, 24, 32.) As a result, the hub-interface may have varying data 
20 transfer granularities (i.e., transfer widths), depending upon the transfer 
rate and the width of the data signal path. For example, in the case of an 
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eight-bit interface width in 4x mode, the transfer width is 32 bits per 
HLCK. As a result, by varying the transfer rate and /or the interface 
width of the data signal path, the transfer width (i.e., number of bytes 
transferred per HLCK) can be scaled. 

5 In addition, in one embodiment, packets may be larger than the 

transfer widths. As a result, the packets are transmitted in multiple 
sections (i.e., packet widths.) In one embodiment, the packets are divided 
into packet widths the size of double words (32 bits). 

In the case of a 32 bit transfer width, the bytes of a packet width are 
10 presented on the interface starting with the least significant byte (byte 0) 
and finishing with the most significant byte (byte 3), as shown below in 
Table 2. In the case of a 64 bit transfer width (e.g., a sixteen bit wide 
interface in 4x mode) the less significant double-word (packet width) is 
transferred on the lower bytes of the data signal (e.g., PD [0:7]) and the 
15 more significant double-word is transferred in parallel on the upper bytes 
of the data signal (e.g., PD [15:8]). The two examples are shown below in 
table 2. 

Table 2 Byte Transmission Order for 8 and 16 Bit Interface Widths 
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HLCLK j: \_JT~^; 


HLCLK /R_j~L_ 




pd[7:o] _EHwB0E 


PD[7:0] JBLlBB 






PD[15:8] -pW® 




8 Bit Interface 


16 Bit Interface 


pf13 



The Protocol Layer of the hub-interface interface is also responsible 
for framing the data. As such, the framing rules implemented by the hub- 
interface define how to map one or more packet widths onto a set of 
5 transfer widths. To simplify the parsing of packets into packet widths, in 
one embodiment of the hub-interface, the following three framing rules 
are implemented: a header section of a packet starts on the first byte of a 
transfer width; a data section of a packet (if present) starts on the first byte 
of a transfer width; and a packet occupies an integral number of transfer 
10 widths. 

Any available transfer widths not consumed by a packet may be 
filled with a double word (DW) transmission, and will be ignored by the 
receiving hub agent. In alternative embodiments, more, less, and /or 
different framing rules may be used by the hub-interface within the scope 
15 of the present invention. 

Table 3 and Table 4 set forth below, illustrate examples of the 
framing rules given above for the case of a 64 bit transfer width. 
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Table 3 Request using 32 Bit Addressing and Containing Three Double- 
words of Data 



4th Byte 3rd Byte 2nd Byte First Byte 4th Byte 3rd Byte 2nd Byte First Byte 

Transmitted Transmitted Transmitted Transmitted Transmitted Transmitted Transmitted Transmitted 

onPD[15:8] onPD[15:8] on PD[15:8] on PD[15:8] on PD[7:0] on PD[7:0] on PD[7:0] on PD[7:0] 

I Byte7 I Byte6 I Byte5 I Byte4 I Byte3 I Byte2 I Byte 1 I Byte 0 I 



Address (32b) 


Request Header 


Second DW of Data 


First DW of Data 


{DW} 


Third DW of Data 
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5 Table 4 Request using 64 Bit Addressing and Containing Three Double- 
words of Data 



4th Byte 3rd Byte 2nd Byte First Byte 4th Byte 3rd Byte 2nd Byte First Byte 

Transmitted Transmitted Transmitted Transmitted Transmitted Transmitted Transmitted Transmitted 

onPD[15:8] on PD[15:8] on PD[15:8] onPD[15:8] on PD[7:0] on PD[7:0] on PD[7:0] on PD[7:0] 

I Byte 7 | Byte 6 I Byte 5 I Byte 4 I Byte 3 I Byte 2 I Byte 1 I ByteO | 



Address (31:2) 


Request Header 


{DW} 


Address (63:32) 


Second DW of Data 


First DW of Data 


{DW} 


Third DW of Data 
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Request Packets 

10 The packet header format for request packets, according to one 

embodiment, is shown below in Table 5 and Table 6. In the examples 
shown in Tables 5 and 6, the base header is one double-word, with one 
additional double-word required for 32 bit addressing, and two additional 
double-words required for the 64 bit addressing mode. The fields of the 

15 headers, as shown in Tables 5 & 6 are described below the tables. 
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In alternative embodiments of the hub-interface, the fields included 
in the header of the request packet may vary without departing from the 
scope of the invention. For example, the header may include additional 
field, less fields, or different fields in place of the fields shown below. 
5 Moreover, the encoding of the fields may also vary without departing 
from the scope of the invention. 

Table 5 Request Packet Header Format for 32 bit Addressing 



Last Byte Transmitted First Byte Transmitted 

31 30 29 28 27 26 25 24|23 22 21 20 19 18 17 16 |l5 14 13 12 11 10 9 8 \l 6 5 4 3 2 1 0 



rq 
cp 


r/ 
w 


cr 


af 


lk 


Transaction Desc. 
Routing Field 


Re- 
served 


TDAttr 


Space 


Data Length (DW) 


Last DW BE 


1 st DW BE 


Addr[3i:2 




R 


ea 
ct 



-Base 



"Address 



10 



Table 6 Request Packet Header Format for 64 bit Addressing 



Last Byte Transmitted First Byte Transmitted 

31 30 29 28 27 26 25 24 123 22 21 20 19 18 17 16 Jl5 14 13 12 11 10 9 8 \l 6 5 4 3 2 1 0 





r/ 


cr 


af 


lk 


Transaction Desc. 


Re- 


TDAttr 


Space 


Data Length (DW) 


Last DW BE 


1 st DW BE 


cp 


w 








Routing Field 


served 













Addr[31:2] 



R ea 



Addr[63:32] 



-Base 
32 bit 

^component 

fc 64bit 
component 



Transaction Descriptor 
15 rq/cp 



cr 



The Transaction Descriptor Routing and 
Attribute fields as previously described. 

Request packets are identified with a '0' and 
completion packets with a '1' in this location. 

Completion required ('1') or no completion 
required ('0'). 
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r/w 



Address Format (af) 



Lock (lk) 



10 



Data Length 



15 Space 



1st DW BE 



20 



25 



Last DW BE 



30 



Addr[31:2] 



35 



Extended Address (ea) 



40 



Read ('0') or Write (T). This field indicates if 
data will be included with a completion (read) 
or a request (write). 

The addressing format is either Implied ('0') or 
32/64 bit (T). 

Flag to indicate that the request is part of a 
locked sequence. Requests and completions in 
a locked sequence will have this bit set. Hub 
agents, which do not comprehend lock, ignore 
this flag and will fill this field with '0'. 

The data length is given in double-words, 
encoded such that the number of double- 
words represented is one plus this number. 
Thus, // 000000 ,/ represents one double-word. 

This field selects the destination space type for 
the request. In one embodiment, possible 
destination spaces include Memory ("00")/ 
and IO ("01"). 

Byte enables for the first double-word of any 
read or write request to Memory or IO. Byte 
enables are active low. If there is only one 
double-word for a request, this byte enable 
field is used. In one embodiment, it is illegal 
to issue a memory or IO read or write request 
with no bytes enabled. 

Byte enables for the last double-word of any 
read or write request. Byte enables are active 
low. If there is only one double-word for a 
request, this field must be inactive ("1111"). 
Byte enables may be discontiguous (e.g.: 
"0101"). This field is never used with special 
cycles since it overlaps the "Special Cycle 
Encoding" field. 

The 32 bit address is generated as it would be 
on PCI for same type of cycle. This double- 
word is included for the 32 and 64 bit 
addressing modes (but not for the implied 
addressing mode). 

Indicates 32 bit addressing ('0') or 64 bit 
addressing ('!'). 
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Config Type (ct) 



For configuration cycles only, this bit is used to 
indicate Type 0 ('0') or Type 1 (T) 
configuration cycle type* Because configuration 
cycles will always be performed with 32 bit 
addressing, this bit is overlapped with the 
"Extended Address" bit. 



Addr[63:32] 



Upper address bits for 64 bit addressing mode. 
This double-word is included for the 64 bit 
addressing mode. 



Completion Packets 



The header format for a completion packet, according to one 
embodiment, is shown below in Table 7. In one embodiment, the header 
15 is one double-word. The fields of the headers, as shown in Table 8 are 
described following the table. 

In alternative embodiments of the hub-interface, however, the 
fields included in the header for a completion packet may vary without 
departing from the scope of the invention. For example, the header may 
20 include additional field, less fields, or different fields in place of the fields 
as described and shown below. Moreover, the encoding of the fields may 
also vary without departing from the scope of the invention. 
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Table 7 Completion Packet Header Format 



Last Byte Transmitted First Byte Transmitted 

31 30 29 28 27 26 25 24 123 22 21 20 19 18 17 16 |l5 14 13 12 11 10 9 8 |7 6 5 4 3 2 1 0 





r/ 


Re- 


lk 


Transaction Desc. 


Re- 


TDAttr 


Rsvd 


Data Length (DW) 


Completion Status 


cp 


w 


served 




Routing Field 


served 











Transaction Descriptor The Transaction Descriptor Routing and 
5 Attribute fields as previously discussed in the 

Transaction section. 

rq/ cp Completion packets are identified with a J V in 

this location. 

r/w Read CO 7 ) or Write (T). This field indicates if 

10 data will be included with a completion (read) 

or a request (write). 

Lock (lk) Flag to indicate that the completion is part of a 

locked sequence. Requests and completions in 
a locked sequence will have this bit set. Agents, 
15 which do not comprehend lock, ignore this flag 

and will fill this field with '0\ 

Data Length The data length is given in double-words, 

encoded such that the number of double- 
words represented is one plus this number. 
20 Thus, // 000000 ,/ represents one double-word. 

Completion Status Indicates completion status using 

predetermined . 

Reserved All reserved bits are set to '0\ 



25 In one embodiment of hub-interface, completions for memory 

reads may provide less than the full amount of data requested so long as 
the entire request is eventually completed. Likewise, completions for 
memory writes may indicate that less than the entire request has been 
completed. This might be done to satisfy a particular hub-interface 

30 interface latency requirement for a particular platform. 
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In addition, for a request that requires completion, the initiator, in 
one embodiment, retains information about the request, which may be 
stored in a buffer of the initiating hub agent. For example, this 
information may include the transaction descriptor, the size of the packet, 
5 lock status, routing information, etc. Furthermore, when receiving the 
completion(s), the initiator matches the completion(s) with the 
corresponding request. In the case of multiple completions, the initiator 
accumulates a count of the data completed for the original request until 
the original request is fully completed. 

10 Interface Arbitration and Packet Framing 

In one embodiment of the hub-interface interface, when the 
interface is idle, the assertion of a request from either hub agent connected 
to the interface, is considered an arbitration event. The first agent to 
request wins ownership of the interface. If agents request ownership 
15 simultaneously when the hub-interface is idle, the least recently serviced 
hub agent wins. In one embodiment, all hub agents track the least 
recently serviced status (e.g., via a status flag of an internal register.) In 
alternative embodiment, alternative arbitration routines may be used 
within the scope of the present invention. 

20 Once a hub agent acquires the ownership of the interface, it will 

continue to own the interface until it completes its transaction, or until an 
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allocated time bandwidth expires. For example, in one embodiment, a 
timeslice counter is provided in each hub agent to control bandwidth 
allocation and to limit an agent's interface ownership tenure. The time 
allotted to a hub agent (i.e., timeslice value) may be different or the same 
5 for hub-interface agents attached to the same interface. The timeslice 
counter is started upon acquiring ownership of interface and counts hub- 
interface base clock periods. 

In one embodiment, each hub agent is responsible for managing its 
own timeslice allocation. As such, in one embodiment, a timeslice value 
10 may be programmed via a hub-interface command register for each 
interface in each hub agent. 

Figure 5 illustrates an example of arbitration for the hub-interface 
interface between hub agent A and agent B and the transfer of two 
packets. The example illustrates arbitration out of an idle interface state, 

15 with the interface then returning to idle. Moreover, in the example 

illustrated, the interface is using a 4x data transfer mode with eight bit 
data signal (PD) path. Agent A, in the example illustrated in Figure 5, is 
the most recently serviced (MRS) agent. As a result, Agent A asserts its 
external request signal (RQA) and samples the state of the Agent B's 

20 request signal (RQB) on clock edge 1 (which is shown to be inactive) 
before starting packet transmission off the same edge. 
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In one embodiment, there is a two clock delay before the 
transmitted data (i.e., data from Agent A) is available internally in the 
receiver (i.e., Agent B), starting from clock edge 3. The first packet 
consists of two double-words 502 and 504 and requires two base clocks to 
5 transmit in the 4x mode. The second packet is three double-words 506, 
508, and 510, and so requires three base clocks in the 4x mode. 

Flow Control 

In one embodiment, packets may be retried or disconnected by a 
receiving agent due to lack of request queue space, data buffer space, or 
10 for other reasons. In one embodiment, Flow control is accomplished using 
a STOP signal. 

Figure 6 illustrates an example of the use of STOP signal. As 
illustrated, Agent A asserts its external request signal (RQA) and samples 
the state of the Agent B's request signal (RQB) on clock edge 1 (which is 
15 shown to be inactive) before starting packet transmission off the same 
edge (e.g., clock edge 1.) 

Following a two clock delay, the data transmitted from Agent A is 
available internally in the receiver at Agent B, starting from clock edge 3. 
In one embodiment, following receipt of data transmitted from Agent A, 
20 is the first opportunity for Agent B to enact flow control by asserting the 
STOP signal, as illustrated in Figure 6, at clock edge 4. 

-27- 042390.P6341X 



In addition, when ownership of PD signal changes from one hub 
agent to another, ownership of the STOP signal will be also be exchanged 
following a predetermined number of clocks. Moreover, in one 
embodiment, the STOP signal is sampled on base clocks, which 
5 correspond to the final transfer of a packet width. For example, in a 4x 
mode (using an eight bit wide PD signal), the STOP signal is sampled each 
base clock. However, for a lx mode, the STOP signal is sampled each 
fourth clock (with the beginning of a transaction being used as a reference 
point). 

10 Following the reception of a STOP signal, the hub agent that 

receives the STOP signal determines whether it may retry sending 
additional packets. Figure 7 is a flow diagram describing the steps 
performed by a hub agent in determining whether it may retry sending a 
packet following receipt of a STOP signal, according to one embodiment. 

15 In step 702, a hub agent that is currently transmitting packets 

receives a STOP signal. In response, in step 704 the hub agent that 
receives the STOP signal determines if the other agent (which activated 
the STOP signal) is requesting ownership of the interface, by sampling the 
other hub agents request signal (e.g., RQB.) 

20 If the recipient of the STOP signal determines that the agent which 

sent the STOP signal is not requesting ownership of the interface, in step 
706 the current owner of the interface may attempt to transmit a packet 
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following recovery from the STOP. On the other hand, if it is determined 
that the agent which activated the STOP signal is requesting ownership, in 
step 708, the current owner determines if its timeslice has expired. 

If the timeslice for the current owner of the interface has expired, in 
5 step 710, the current owner releases ownership* If the timeslice for the 
current owner has not expired, the current owner may transmit a packet 
with an attribute that is different from the interrupted packet. More 
specifically, in step 712, the current owner determines if it has a packet 
with a attribute type that is different from any packets that have been 
10 retried in the present arbitration session (i.e., the period of the current 
owner's tenure), which needs to be transmitted. 

If the current owner does have a packet with a different attribute, 
in step 714 the current owner may attempt to transmit the packet. 
Otherwise, the current owner release ownership of the interface. 

15 PHYSICAL INTERFACE 

In one embodiment, the hub-interface interface implements a 
physical interface that operates at a base frequency of either 66MHz or 
100MHz. Other frequencies may also be used. In addition, in one 
embodiment, the physical interface uses a source synchronous (SS) data 
20 transfer technique which can be quad-clocked to transfer data at 4X of the 
base hub-interface clock. As a result, in an embodiment having an 8-bit 



-29- 



042390.P6341X 



data interface (e.g., PD) operating at a base frequency of 66MHz or 
100MHz, a bandwidth of 266 megabytes per second (MB/s) or 400MB/ s 
may be achieved, respectively. 

Furthermore, in one embodiment, the hub-interface interface 
5 supports a voltage operation of 1.8V, and is based on complementary 
metal-oxide semiconductor process (CMOS) signaling. In an alternative 
embodiments, however, the interface may operate at alternative 
frequencies and/or alternative sized data interfaces to provide varying 
bandwidths, and support alternative operating voltages, based on 
10 alternative signal processing, without departing from the scope of the 
invention. 

External Signals Definition 

Figure 8 illustrates the physical signal interface of the hub-interface 
between two hub agents, according to one embodiment. As shown in 

15 Figure 8, the hub-interface physical interface uses a bi-directional eight bit 
data bus (PD [7:0]) with a differential pair of source synchronous strobe 
signals (PSTRBN, PSTRBP) for data clocking. In an alternative 
embodiment, the interface can widened. For example, as shown in Figure 
8, an additional eight bit data bus (PD [15:8]) can also be used along with 

20 an additional pair of pair of source synchronous strobe signals 

(PUSTRBN, PUSTRBP.) Moreover, in an alternative embodiment, 
unidirectional data signals could be used. 
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In addition, one unidirectional arbitration signal connects each 
agent to the other (RQa, RQb), and a bi-directional STOP signal is used by 
the receiving agent to control data flow, as previously described. 
Additional interface signals include the system reset (Reset), common 
5 clock (HLCLK) and voltage reference signals (HLVREF). As well, signals 
for each hub agent (ZCOMP) to match its driver output impedance to the 
appropriate value to compensate for manufacturing and temperature 
variations, are also included. 

The physical signals shown in the interface illustrated in Figure 8 
10 are further described below in Table 8. In alternative embodiments of the 
hub-interface, the signals included in the physical interface may vary 
without departing from the scope of the invention. For example, the 
physical interface may include more, less or different signals varying from 
the signals shown in Figure 8 and further described below in Table 8. 



-31- 



042390.P6341X 



Table 8 Hub-interface Interface Signals for Eight Bit Agents 







W&M 1 






PD[7:0] 


8 


ASTS 1 


ss 2 


Packet data pins. The data interface when idle, in one 








embodiment, is held by active sustainers at the last 
voltage value to which it was driven. 


PSTRBP 


1 


ASTS 


ss 


Negative PD Interface Strobe (default voltage level = 








VSSHL) and Positive PD Interface Strobe (idle voltage 
level = VCCHL) together provide timing for 4X and IX 
data transfer on the PD[7:0] interface. The agent that is 
providing data drives this signal. PSTRBN and PSTRBP 
should be sensed fully differentially at the receiver. 


PSTRBN 


1 


ASTS 


ss 


Positive PD Interface Strobe, see PSTRBP description 
above. 


RQa 


1 


I/O 


cc 3 


Active-high request from agent A (output from A, 








input to B) to obtain ownership of the hub-interface 
interface. RQa is asserted when agent A has data 
available to send, and is deasserted when either all of 
agent A's data has been sent or agent A determines that 
it should release the interface. Reset voltage value is 
VSSHL. 


RQb 


1 


I/O 


cc 


Request from agent B (output from B, input to A). See 








above description of RQa. 


STOP 


1 


ASTS 


cc 


Used for pipelined flow control to retry or disconnect 
packets. 


HLCLK 


1 


I 


N/A 


hub-interface base clock, in one embodiment, either 
66MHz or 100MHz. This provides timing information 
for the common clock signals (described further below. 


RESET# 


1 


I 


CC 


Active-low reset indication to hub-interface agents. 4 


HLVREF 


1 


I 


N/A 


Voltage reference (VCCHL/2) for differential inputs. 
In one embodiment, the voltage is generated on the 
motherboard through a voltage divider. 


HLZCOMP 


1 


I/O 


N/A 


Provides Impedance Compensation. 


VCCHL 


4 


power 


N/A 


1.8V 


VSSHL 


4 


ground 


N/A 




Total: 


25 









1 ASTS = Actively Sustained Tri-State. 

2 SS = Source Synchronous Mode Signal 

3 CC = Common Clock Mode Signal 

4 In one embodiment, Reset is a system-wide signal; it is an output from 
one component of the system and an input to the other component(s). 
Moreover, Reset is asynchronous with respect to HLCLK. 
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rnmmnn Clock Transfer Mo de Operation 
In one embodiment, many of the signals transmitted across the 
hub-interface interface are transmitted in accordance with a common clock 

5 mode. More specifically, the timing of the signals that are transmitted via 
the common clock mode are referenced to a single clock (e.g., the hub- 
interface clock.) In alternative embodiments, the signals may be tied to a 
system clock, exterior to the hub-interface agents. Moreover, there may be 
more than one hub-interface segment in a system, in which case different 

10 base clocks may be used for the different segments. For example, one 
component might implement both a 66MHz base hub-interface interface 
and a 100MHz base hub-interface interface. 

Source Synchronous Transfer Mode Operation 
In one embodiment, the packets/ data are transmitted using a 
1 5 source synchronous clock mode, which provides a technique for 
multiplying the data transfer rate of data. For example, in an 
embodiment using 4X source synchronous clocking mode with an eight 
bit data signal path, transmitting a double-word (i.e., four byte) requires 
only one hub-interface clock cycle (HLCK.) Alternatively, transmitting a 
20 double word using IX source synchronous clocking mode on an eight bit 
data signal path would require a full hub-interface clock cycle to complete. 



-33- 



042390.P6341X 



More specifically, in one embodiment of source synchronous 
transmission, strobes (e.g., PSTRBN/PSTRBP) are sent with a data 
transmission in accordance with a predetermined timing relationship 
between the strobes and the data. The strobes are thereafter used by the 
5 receiving hub agent to latch the data into the receiving hub agent. 

More specifically, in one embodiment, the edges of the strobes 
PSTRBP/PSTRBN are used by the receiving hub agent to identify the 
presence and timing of data being transferred across the data signal paths. 
For example, as illustrated in the timing diagram of Figure 9, in one 
10 embodiment a first data transfer corresponds to the rising edge of PSTRBP 
and the falling edge of PSTRBN. A second data transfer corresponds to 
the rising edge of PSTRBN and the falling edge of PSTRBP. 

In addition, in one embodiment, as further shown in Figure 9, the 
transmit edges of the strobes PSTRBP/PSTRBN are positioned near the 

15 center of the data valid window. As a result, the receiving agent is given 
an input data sampling window to accommodate various system timing 
skews. Moreover, in one embodiment a minimum data valid before 
strobe edge (tDvb), and a minimum data valid after strobe edge (tDva) are 
also used by the receiving hub agent to identify and latch data being 

20 transmitted. Once the receiving hub agent latches the incoming data, the 
data is thereafter held for brief period to resynchronize the data with the 



-34- 



042390.P6341X 



hub-interface clock (HLCK) before being passed along within the hub 
agent. 



In the foregoing specification the invention has been described with 
5 reference to specific exemplary embodiments thereof. It will, however, be 
evident that various modifications and changes may be made thereto 
without departing from the broader spirit and scope of the invention. For 
example, the hub-interface interface, according to one embodiment, may 
be implemented in a computer system having multiple processors, as 
10 illustrated in Figure 10. The specification and drawings are, as a result, to 
be regarded in an illustrative rather than a restrictive sense. 
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t 

CLAIMS 

What is claimed is: 

1 1. An interface to transfer data directly between a memory control hub (MCH) and 

2 a input/output control hub (ICH) within a computer system, comprising: 

3 a data signal path to transmit data in packets via split transactions; and 

4 a set of command signals, wherein said interface provides a point-to-point 

5 connection between said MCH and said ICH, exclusive of an external bus 

6 connected directly to the interface. 

1 2. The interface of claim 1, wherein said MCH and said ICH within said computer 

12 system are components within a chipset. 

% 3. The interface of claim 1, wherein a first transaction is initiated on said interface 

12 with a request packet, subsequent to arbitration for ownership of said interface. 

;1 4. The interface of claim 3, wherein said request packet includes a transaction 

112 descriptor. 

1 5. The interface of claim 3, wherein a completion packet is transmitted on said 

2 interface in response to said request packet of said first transaction. 

1 6. The interface of claim 3, wherein said request packet includes transaction 

2 descriptor and said completion packet includes a corresponding transaction descriptor. 

1 7. The interface of claim 5, wherein a request packet for a second transaction can be 

2 transmitted across said interface prior to transmitting said completion packet in 

3 response to the request packet of said first transaction. 
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1 



8. The interface of claim 3, wherein said data signal path is scalable. 



1 9. The interface of claim 8, wherein packets are transmitted across said data signal 

2 path via a source synchronous clock mode. 

1 10. The interface of claim 9, wherein said interface includes a set of bi-directional 

2 data signals, a first and second source synchronous strobe signal, a unidirectional 

3 arbitration signal, and a bi-directional stop signal 

ill 11. The interface of claim 10, wherein said interface further includes a system reset 

5> signal, a common clock signal, and a voltage reference signal. 

Ill 12. The interface of claim 11, wherein said transaction descriptors identify separate 

"2 hubs within a hierarchy of multiple interfaces between at least three hubs. 

lh 13. The interface of claim 5, wherein said request packet includes a field indicating if 

32 a completion packet is required in response to the respective request packet. 

1 14. The interface of claim 3, wherein arbitration between said hubs is symmetric and 

2 distributed. 

1 15. The interface of claim 3, wherein a hub is allotted ownership of said interface up 

2 to a predetermined amount of time. 

1 16. An interface to transfer data directly between a memory control hub (MCH) and 

2 an input/output control hub (ICH) within a computer system, comprising: 
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3 a first means for transmitting data between said MCH and said ICH in packets 

4 via split transactions; and 

5 a second means for transmitting command signals, wherein said interface 

6 provides a point-to-point connection between said MCH and said ICH, exclusive 

7 of an external bus connected directly to the interface. 

1 17. The interface of claim 16, wherein said ICH and said MCH within said computer 

2 system are components within a chipset. 

1 18. The interface of claim 17, wherein said interface includes a means for initiating a 

:|2 first transaction on said interface with a request packet. 

il 19. The interface of claim 18, wherein said request packet includes a transaction 

"2 descriptor. 

1 1 20. The interface of claim 19, wherein said interface includes means for providing a 

u2 completion packet in response to said request packet of said first transaction. 

1 21. The interface of claim 18, wherein said request packet includes a transaction 

2 descriptor and said completion packet includes a corresponding transaction descriptor. 

1 22. The interface of claim 21, wherein said interface includes a means for 

2 transmitting request packet for a second transaction across said interface prior to 

3 transmitting said completion packet in response to the request packet of said first 

4 transaction. 
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1 23. The interface of claim 22, wherein said first means for transmitting data in 

2 packets via split transactions includes further includes means for scaling a data signal 

3 path. 

1 24. The interface of claim 23, wherein said interface includes means for transmitting 

2 packets across said interface via a source synchronous clock mode. 

1 25. The interface of claim 21, wherein said transaction descriptors include a means 

2 for identifying separate hubs within a hierarchy of multiple interfaces between three or 

3 more hubs. 

A 26. The interface of claim 20, wherein said request packet includes a means for 

i indicating if a completion packet is required in response to the respective request 

"3 packet. 

4 27. The interface of claim 26, wherein interface includes a means for arbitrating 
12 between said hubs for ownership of said interface. 

1 28. The interface of claim 21, wherein said interface further includes a means for is 

2 allotting ownership of said interface to one of said hubs up to a predetermined amount 

3 of time. 

1 29. An interface to transfer data between a memory control hub and an 

2 input/ output (1/ O) hub of a chipset within a computer system, comprising: 

3 a bi-directional data signal path and a pair of source synchronous strobe signals, 

4 said data signal path transmits data in packets via split transactions, said packets 
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5 including a request packet and completion packet, said request packet including a 

6 transaction descriptor ; and 

7 a set of command signals including unidirectional arbitration signal, a bi- 

8 directional stop signal, a system reset signal, a common clock signal, and a voltage 

9 reference signal, wherein said interface provides a point-to-point connection between 

10 said memory control hub and said I/O hub, exclusive of an external bus connected 

1 1 directly to the point-to-point connection. 



1 30. A computer system comprising 

2 a processor; 

f -3 a memory control hub (MCH) coupled to said processor; 

' i an input/output control hub (ICH) coupled to said MCH via an interface to 

I J transfer data directly between the MCH and the ICH; 

\% said interface having a data signal path to transmit data in packets via split 



transactions, and said interface including a set of command signals, wherein said 
interface provides a point-to-point connection between said MCH and said ICH, 

!\B exclusive of an external bus connected directly to the point-to-point connection; and 

sff) at least one peripheral component coupled to said ICH. 

1 31. The computer system of claim 30, wherein said peripheral component is a 

2 Peripheral Component Interconnect (PCI) agent. 

1 

2 32. The computer system of claim 31, wherein said first and second hubs within said 

3 computer system are components within a chipset. 
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1 33. The computer system of claim 32, wherein a first transaction is initiated on said 

2 interface with a request packet, subsequent to arbitration for ownership of said 

3 interface. 

1 34. The computer system of claim 33, wherein said request packet includes a 

2 transaction descriptor. 

1 35. The computer system of claim 33, wherein a completion packet is transmitted on 

2 said interface in response to said request packet of said first transaction. 

31 36. The computer system of claim 35, wherein said request packet includes a 

;2 transaction descriptor and said completion packet includes a corresponding transaction 

S3 descriptor. 

"1 37. The computer system of claim 36, wherein a request packet for a second 

f2 transaction can be transmitted across said interface prior to transmitting said 

113 completion packet in response to the request packet of said first transaction. 

1 38. The computer system of claim 36, wherein said data signal path is scalable. 

1 39. The computer system of claim 38, wherein packets are transmitted across said 

2 data signal path via a source synchronous clock mode. 

1 40. The computer system of claim 39, wherein said interface includes a set of bi- 

2 directional data signals, a first and second source synchronous strobe signal, a 

3 unidirectional arbitration signal, and a bi-directional stop signal. 
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1 41 . The computer system of claim 40, wherein said interface further includes a 

2 system reset signal, a common clock signal, and a voltage reference signal. 

1 42. The computer system of claim 41, wherein said transaction descriptors identify 

2 separate hubs within a hierarchy of multiple interfaces between at least three hubs. 

1 43. The computer system of claim 42, wherein said request packet includes a field 

2 indicating if a completion packet is required in response to the respective request 

3 packet. 

*1 44. The computer system of claim 43, wherein arbitration between said hubs is 

S2 symmetric and distributed. 

£ 1 45. The computer system of claim 44, wherein a hub is allotted ownership of said 

z 2 interface up to a predetermined amount of time. 

U 1 46. The computer system of claim 31, wherein the computer system includes 

32 multiple processors. 

1 47. The computer system of claim 31, wherein the computer system further includes a 

2 third hub coupled to said ICH via an interface comprising: 

3 a bi-directional data signal path and a pair of source synchronous strobe signals, 

4 said data signal path transmits data in packets via split transactions, said packets 

5 including a request packet and completion packet, said request packet including a 

6 transaction descriptor ; and 
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7 a set of command signals including unidirectional arbitration signal, a bi- 

8 directional stop signal, a system reset signal, a common clock signal, and a voltage 

9 reference signal. 

1 48. The computer system of claim 31, wherein the processor and the MCH of said 

2 computer system, are integrated on a single semiconductor unit. 

1 49. The computer system of claim 31, wherein the MCH and a graphics unit of said 

2 computer system, are integrated on a single semiconductor unit. 

*(1 50. A memory control hub (MCH) comprising: 

22 an interface to transfer data directly to an input/output control hub (ICH) within 

% 3 a computer system, the interface having a data signal path to transmit data in 

*4 packets via split transactions, and a set of command signals, wherein the 

« 5 interface provides a point-to-point connection between said the MCH and said 

~6 ICH, exclusive of an external bus connected directly to the interface. 

3 1 51. The memory control hub of claim 50, wherein said MCH and ICH are 

2 components within a chipset. 

1 52. The memory control hub of claim 50, wherein a first transaction is initiated on 

2 said interface with a request packet, subsequent to arbitration for ownership of said 

3 interface. 

1 53. The memory control hub of claim 52, wherein said request packet includes a 

2 transaction descriptor. 
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1 54. The memory control hub of claim 53, wherein a completion packet is transmitted 

2 on said interface in response to said request packet of said first transaction. 

1 55. The memory control hub of claim 52, wherein said request packet includes 

2 transaction descriptor and said completion packet includes a corresponding transaction 

3 descriptor* 

1 56. The memory control hub of claim 55, wherein a request packet for a second 

2 transaction can be transmitted across said interface prior to transmitting said 

3 completion packet in response to the request packet of said first transaction. 

i 57. The memory control hub of claim 56, wherein said data signal path is scalable. 

1 59. The memory control hub of claim 57, wherein packets are transmitted across said 

2 data signal path via a source synchronous clock mode. 

LjL 60. The memory control hub of claim 59, wherein said interface includes a set of bi- 

3> directional data signals, a first and second source synchronous strobe signal, a 

1i unidirectional arbitration signal, and a bi-directional stop signal. 

1 61. The memory control hub of claim 60, wherein said interface further includes a 

2 system reset signal, a common clock signal, and a voltage reference signal. 

1 62. The memory control hub of claim 61, wherein said transaction descriptors 

2 identify separate hubs within a hierarchy of multiple interfaces between at least three 

3 hubs. 



-44- 



042390.P6341X 



1 63. The memory control hub of claim 62, wherein said request packet includes a field 

2 indicating if a completion packet is required in response to the respective request 

3 packet. 

1 64. The memory control hub of claim 63, wherein arbitration between said hubs is 

2 symmetric and distributed. 

1 65. The memory control hub of claim 64, wherein a hub is allotted ownership of said 

2 interface up to a predetermined amount of time. 

JL 66. The memory control hub of claim 50, wherein the memory control hub and a 
i processor are integrated on a single semiconductor unit. 

*1 67. The memory control hub of claim 50, wherein the memory control hub and a 

=2 graphics unit are integrated on a single semiconductor unit. 
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ABSTRACT 



An interface to transfer data between a memory control hub and an 
input/output control hub of a chipset within a computer system. One 
embodiment of the interface includes a bi-directional data signal path and 
a pair of source synchronous strobe signals. The data signal path 
transmits data in packets via split transactions. In addition, the packets 
include a request packet and a completion packet, if necessary. 
Furthermore, in one embodiment, the request packets include a 
transaction descriptor. 
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Attorney's Docket No.: 042390.P6341X 



PATENT 



DECLARATION AND POWER OF ATTORNEY FOR PATENT APPLICATION 
(CONTINUATION-IN-PART) 

As a below named inventor, I hereby declare that: 

My residence, post office address and citizenship are as stated below, next to my name. 

I believe I am the original, first, and sole inventor (if only one name is listed below) or an original, first, 
and joint inventor (if plural names are listed below) of the subject matter which is claimed and for 
which a patent is sought on the invention entitled Method And Apparatus For An Improved Interface 
Between Components. 



the specification of which 



X 



is attached hereto, 
was filed on 



United States Application Number 

or PCT International Application Number, 
and was amended on 



as 



(if applicable) 

I hereby state that I have reviewed and understand the contents of the above-identified specification, 
including the claims, as amended by any amendment referred to above. 

I acknowledge the duty to disclose all information known to me to be material to patentability as 
defined in Title 37, Code of Federal Regulations, Section 1 .56. 

I hereby claim foreign priority benefits under Title 35, United States Code, Section 1 19(a)-(d), of any 
foreign application(s) for patent or inventor's certificate listed below and have also identified below any 
foreign application for patent or inventor's certificate having a filing date before that of the application 
on which priority is claimed: 



Prior Foreign Application(s) 



Priority 
Claimed 



(Number) 



(Country) 



(Day/Month/Year Filed) Yes No 



(Number) 



(Country) 



(Day/Month/Year Filed) Yes No 



(Number) 



(Country) 



(Day/Month/Year Filed) 



Yes No 



I hereby claim the benefit under title 35, United States Code, Section 1 1 9(e) of any United States 
provisional application(s) listed below: 



Application Number 



Filing Date 



Application Number 



Filing Date 
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I hereby claim the benefit under Title 35. United States Code. Section 120 of any United States 
a pplication^ listed below and, insofar as the subject matter of each of the claims of this 
application is not disclosed in the prior United States application in the manner provided by 
the first paragraph of Title 35, United States Code, Section 112, 1 acknowledge the duty to 
disclose all information known to me to be material to patentability as defined in Title 37, Code 
of Federal Regulations, Section 1.56 which became available between the filing date of the 
prior application and the national or PCT international filing date of this application: 

08/186.219 November 3. 1998 Pending 

Application Number Filing Date Status patented, 

pending, abandoned 



Application Number Filing Date Status - patented, 

pending, abandoned 



I hereby appoint the persons listed on Appendix A hereto (which is incorporated by reference and a 
part of this document) as my respective patent attorneys and patent agents, with full power of 
substitution and revocation, to prosecute this application and to transact all business in the Patent 
and Trademark Office connected herewith. 

Send correspondence to John P. Ward , BLAKELY, SOKOLOFF, TAYLOR & 

(Name of Attorney or Agent) 
ZAFMAN LLP, 12400 Wilshire Boulevard 7th Floor, Los Angeles, California 90025 and direct 

telephone calls to John P. Ward (408) 720-8598. 

(Name of Attorney or Agent) 

I hereby declare that all statements made herein of my own knowledge are true and that all 
statements made on information and belief are believed to be true; and further that these 
statements were made with the knowledge that willful false statements and the like so made 
are punishable by fine or imprisonment, or both, under Section 1001 of Title 18 of the United 
States Code and that such willful false statements may jeopardize the validity of the 
application or any patent issued thereon. 



Full Name of Sole/First Inventor Jasmin Aianovic 

Inventor's Signature Date 

Residence Folsom. California Citizenship U.S.A. 

(City, State) (Country) 

Post Office Address 106 Woodard Lane 

Folsom. California 95630 



Full Name of Second/Joint Inventor David J. Harriman 

Inventor's Signature Date 

Residence Sacramento. California Citizenship U.S.A. 

(City, State) (Country) 

Post Office Address 2941 Highland Avenue 

Sacramento. California 95818 
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APPENDIX A 



William E. Alford, Reg. No. 37,764; Farzad E. Amini, Reg. No. P42.261; Aloysius T. C. AuYeung, Reg. No. 
35 432; William Thomas Babbitt, Reg. No. 39,591; Carol F. Barry, Reg. No. 41,600; Jordan Michael 
Becker, Reg. No. 39,602; Bradley J. Bereznak, Reg. No. 33,474; Michael A. Bernadicou, Reg. No. 35,934; 
Roger W. Blakely, Jr., Reg. No. 25,831; Gregory D. Caldwell, Reg. No. 39,926; Ronald C. Card, Reg. No. 
P44 587- Thomas M. Coester, Reg. No. 39,637; Stephen M. De Klerk, under 37 C.F.R. § 10.9(b); Michael 
Anthony DeSanctis, Reg. No. 39,957; Daniel M. De Vos, Reg. No. 37,813; Robert Andrew Diehl, Reg. No. 
40 992; Matthew C. Fagan, Reg. No. 37,542; Tarek N. Fahmi, Reg. No. 41,402; James Y. Go, Reg. No. 
40 621; James A. Henry, Reg. No. 41,064; Willmore F. Holbrow III, Reg. No. P41 ,845; Sheryl Sue 
Holloway, Reg. No. 37,850; George W Hoover II, Reg. No. 32,992; Eric S. Hyman, Reg. No. 30,139; Dag 
H Johansen, Reg. No. 36,172; William W. Kidd, Reg. No. 31,772; Erica W. Kuo, Reg. No. 42,775; Michael 
J. Mallie, Reg. No. 36,591; Andre L. Marais, under 37 C.F.R. § 10.9(b); Paul A. Mendonsa, Reg. No. 
42,879; Darren J. Milliken, Reg. 42,004; Lisa A. Norris, Reg. No. P44.976; Chun M. Ng, Reg. No. 36,878; 
Th'ien f. Nguyen, Reg. No. 43,835; Thinh V. Nguyen, Reg. No. 42,034; Dennis A. Nicholls, Reg. No, 
42,036; Kimberley G. Nobles, Reg. No. 38,255; Daniel E. Ovanezian, Reg. No. 41 ,236; Babak Redjaian, 
Reg. No. 42,096; William F. Ryann, Reg. 44,313; James H. Salter, Reg. No. 35,668; William W. Schaal, 
Reg No. 39,018; James C. Scheller, Reg. No. 31,195; Jeffrey Sam Smith, Reg. No. 39,377; Maria 
McCormack Sobrino, Reg. No. 31,639; Stanley W. Sokoloff, Reg. No. 25,128; Judith A. Szepesi, Reg. No. 
39,393; Vincent P. Tassinari, Reg. No. 42,179; Edwin H. Taylor, Reg. No. 25,129; John F. Travis, Reg. 
No. 43,203; George G. C. Tseng, Reg. No. 41,355; Joseph A. Twarowski, Reg. No. 42,191 ; Lester J. 
Vincent, Reg. No. 31,460; Glenn E. Von Tersch, Reg. No. 41,364; John Patrick Ward, Reg. No. 40,216; 
Charles T. J. Weigell, Reg. No. 43,398; Kirk D. Williams, Reg. No. 42,229; James M. Wu, Reg. No. 
P45.241; Steven D. Yates, Reg. No. 42,242; Ben J. Yorks, Reg. No. 33,609; and Norman Zafman, Reg. 
No. 26,250; my patent attorneys, and Andrew C. Chen, Reg. No. 43,544; Justin M. Dillon, Reg. No. 
42,486; Paramita Ghosh, Reg. No. 42,806; and Sang Hui Kim, Reg. No. 40,450; my patent agents, of 
BLAKELY, SOKOLOFF, TAYLOR & ZAFMAN LLP, with offices located at 12400 Wilshire Boulevard, 7th 
Floor, Los' Angeles, California 90025, telephone (310) 207-3800, and James R. Thein, Reg. No. 31,710, 
my patent attorney. 
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Title 37, Code of Federal Regulations, Section 1.56 
Duty to Disclose Information Material to Patentability 

(a) A patent by its very nature is affected with a public interest. The public interest is best served, 
and the most effective patent examination occurs when, at the time an application is being examined, the 
Office is aware of and evaluates the teachings of ail information material to patentability. Each individual 
associated with the filing and prosecution of a patent application has a duty of candor and good faith in 
dealing with the Office, which includes a duty to disclose to the Office all information known to that individual 
to be material to patentability as defined in this section. The duty to disclosure information exists with respect 
to each pending claim until the claim is cancelled or withdrawn from consideration, or the application becomes 
abandoned. Information material to the patentability of a claim that is cancelled or withdrawn from 
consideration need not be submitted if the information is not material to the patentability of any claim 
remaining under consideration in the application. There is no duty to submit information which is not material 
to the patentability of any existing claim. The duty to disclosure all information known to be material to 
patentability is deemed to be satisfied if all information known to be material to patentability of any claim 
issued in a patent was cited by the Office or submitted to the Office in the manner prescribed by §§1 .97(b)-(d) 
and 1 .98. However, no patent will be granted on an application in connection with which fraud on the Office 
was practiced or attempted or the duty of disclosure was violated through bad faith or intentional misconduct. 
The Office encourages applicants to carefully examine: 

(1) Prior art cited in search reports of a foreign patent office in a counterpart application, and 

(2) The closest information over which individuals associated with the filing or prosecution of a 
patent application believe any pending claim patentably defines, to make sure that any material information 
contained therein is disclosed to the Office. 

(b) Under this section, information is material to patentability when it is not cumulative to 
information already of record or being made or record in the application, and 

(1) It establishes, by itself or in combination with other information, a prima facie case of 
unpatentability of a claim; or 

(2) It refutes, or is inconsistent with, a position the applicant takes in: 

(i) Opposing an argument of unpatentability relied on by the Office, or 

(ii) Asserting an argument of patentability. 

A prima facie case of unpatentability is established when the information compels a conclusion that a claim is 
unpatentable under the preponderance of evidence, burden-of-proof standard, giving each term in the claim 
its broadest reasonable construction consistent with the specification, and before any consideration is given to 
evidence which may be submitted in an attempt to establish a contrary conclusion of patentability. 

(c) Individuals associated with the filing or prosecution of a patent application within the 
meaning of this section are: 

(1) Each inventor named in the application; 

(2) Each attorney or agent who prepares or prosecutes the application; and 

(3) Every other person who is substantively involved in the preparation or prosecution of the 
application and who is associated with the inventor, with the assignee or with anyone to whom there is an 
obligation to assign the application. 

(d) Individuals other than the attorney, agent or inventor may comply with this section by 
disclosing information to the attorney, agent, or inventor. 



